Many plain traffic flows (5 tupple) can be secured under the hood of one Internet Protocol Security (IPSec) tunnel. Tunnel mode is used to create virtual private networks for network-to-network communications (e.g. between routers to link sites), host-to-network communications (e.g. remote user access) and host-to-host communications (e.g. private chat). In tunnel mode, the entire IP packet is encrypted and/or authenticated. It is then encapsulated into a new IP packet with a new IP header.
IPSec secures the plain packet by encapsulating with a security header. IPSec protocol mandates a monotonically increasing sequence number to be present in the security header of every packet that uses the IPSec tunnel. The granularity of the sequence number is per tunnel but not at flow granularity. The sender generates this sequence number for every packet and the receiver maintains a sequence number sliding window for each tunnel. Packets with the sequence numbers that are lower than the current sequence window are dropped by the receiver as a method of preventing a replay attack. The protocol allows packets with sequence numbers that fall within the sequence window or to the right side of (i.e., greater than) the sequence window.
The sequence number checking performed in an anti-replay protocol forces serialization of the packet processing. Such serialization degrades throughput performance in the case of shared memory multi core systems or distributed cluster packet processing environments where packets cannot be effectively distributed to all of the processing units since the sequence numbers are read and updated on per packet basis.
In case of multi core environments, maintaining the integrity of the sequence number value results in taking locks to serialize the packet processing which results in a reduction of the overall throughput. In the case of non memory shared cluster systems, maintaining the integrity of the sequence number is even more difficult since the state actually need to traverse memory boundaries.